\documentclass[12pt,twoside,doublepage]{article}

% Hier den Namen des Teilnehmers und den Titel  der Ausarbeitung eintragen:
\newcommand{\teilnehmer}{Sascha Abram - sabram@mail.upb.de}
\newcommand{\ausarbeitung}{Proposal zur Bachelorarbeit}

\usepackage[utf8]{inputenc}
\usepackage[german]{babel}
\usepackage[T1]{fontenc}
\selectlanguage{german}
\usepackage{times}
\usepackage{url}
\usepackage{listings}
\usepackage{lscape} 
\usepackage{color}
\usepackage{colortbl}
\definecolor{hellgrau}{rgb}{0.95,0.95,0.95}

\usepackage{geometry}
\geometry{a4paper,body={5.8in,9in}}

\usepackage{graphicx}
\graphicspath{{figures/}}

\usepackage{fancyhdr}
\pagestyle{fancy}
\fancyhead{}
\fancyhead[LE]{ \slshape \teilnehmer}
\fancyhead[LO]{}
\fancyhead[RE]{}
\fancyhead[RO]{ \slshape \ausarbeitung}
\fancyfoot[C]{}

\begin{document}

\title{\ausarbeitung}
\author{\teilnehmer}
\date{Eine Entwicklungsumgebung für die Übersetzer-Generierung mit Eli auf Basis von Eclipse}
\maketitle
\section{Einleitung}
\label{sec:einleitung}
\hyphenation{ LITERATE }
Moderne Übersetzer für Programmiersprachen und anwendungsspezifische Sprachen lassen sich in zwei Hauptphasen unterteilen. Die Analysephase, auch Frontend genannt, ist die erste der beiden sequenziell ausgeführten Phasen. Ihr folgt die Synthesephase oder auch Backend genannt. Diese Phasen sind selbst wieder gegliedert, sodass das Frontend aus der lexikalischen, der syntaktischen und der semantischen Analyse sowie der Transformation besteht. Das Backend besteht aus der Optimierung, der Code Generierung und der Assemblierung.
Die Phasen innerhalb der Analyse oder Synthese werden zunehmend werkzeuggestützt entwickelt, um auf bereits bekannte und bewährte Methoden zurückzugreifen.

Eli \cite{eli} ist ein Werkzeugsystem, das optimierte Werkzeuge für die Implementierung der einzelnen Phasen des Übersetzers anbietet. So ist zum Beispiel das Werkzeug GLA als Bestandteil von Eli, für die Generierung des Scanners verantwortlich. Der Scanner wird in der lexikalischen Analyse dazu genutzt Tokens zu identifizieren und für die weitere Verwendung entsprechend zu kodieren. Um die Generierung des Scanners zu ermöglichen, benötigt GLA eine Spezifikation der Schreibweise der möglichen Tokens. Diese Spezifikation wird in einer oder mehreren gla - Dateien gespeichert.

Aufgabe eines Entwicklers ist es an dieser Stelle, alle Spezifikationen zu entwickeln die Eli für die Generierung des Übersetzers benötigt. Die Spezifikationen werden in unterschiedlichen formalen Kalkülen formuliert, die entsprechend der Syntax des Werkzeugs definiert werden müssen.

Die derzeitige Vorgehensweise bei der Arbeit mit Eli lässt sich wie folgt beschreiben: 
Der Entwickler muss mithilfe eines einfachen Texteditors eine zusammenhängende Spezifikation von verschiedenen Übersetzeraufgaben, formuliert in den verschiedenen Spezifikationssprachen, verfassen. Die einzelnen Teilspezifikationen dienen als Eingabe für die Eli-Werkzeuge. Die Eli-Werkzeuge und die damit verbundenen Spezifikationssprachen werden in Kapitel~\ref{subsec:eli} genauer eingeführt und in die sequentiellen Phasen des Übersetzers eingeordnet. 
Nachdem die zusammenhängende Spezifikation, in Form einer spec-Datei an Eli übergeben wurde wertet Eli sie mit den darin enthaltenen Eingaben für die einzelnen Werkzeuge aus und gibt diese weiter. Fehler innerhalb der Spezifikationen werden durch die Werkzeuge selbstständig an Eli zurückgemeldet und in der Konsole angezeigt.

Eine weitere Vorgehensweise bei der Arbeit mit Eli ist die Literate-Programmming Schnittstelle durch eine FunnelWeb-Spezifikation. Eine FunnelWeb-Spezifikation erlaubt es, eine vollständige Eli Spezifkation mit Dokumentation und Kommentaren zu den einzelnen Spezifikationsfragmenten zu verweben. In Kapitel~\ref{subsec:beister} wird eine Arbeit von Frederic Beister vorgestellt, die sich mit einer Entwicklungsumgebung zur Unterstützung bei FunnelWeb-Spezifikationen beschäftigte. 
Die unter dem Namen LITERATE erarbeitete Entwicklungsumgebung kann, aufgrund der Verwobenheit einer FunnelWeb-Spezifikation, keine Syntaxunterstützung für die einzelnen Eli Spezifikationssprachen gewährleisten. Aus diesen Grund wird sich diese Arbeit nicht weiter mit dieser Art der Eli Spezifikation beschäftigen.

Ziel dieser Arbeit ist es eine Entwicklungsumgebung für Eli Projekte zu entwickeln, die den Nutzer bei der Arbeit mit Eli und den einzelnen Spezifikationssprachen unterstützt. Hierzu werden syntaxgestützte Editorn auf Basis von Eclipse für die Eli Werkzeuge gla, con, liga, ptg und ihre zugehörige Spezifikationssprachen entwickelt. Die Editoren sollen generelle Komfortfunktionen, die aus der Arbeit mit Eclipse bekannt sind, implementieren. Hierzu gehören Syntaxhervorhebung, Kontextvervollständigung sowie eine verbesserte Fehlerkennzeichnung. Zusätzlich zu den Editoren, soll innerhalb von Eclipse eine Schnittstelle für Eli implementiert werden, die es erlaubt einen Großteil der textuellen Befehle für Eli leichter umzusetzen. Diese Schnittstelle soll außerdem die Möglichkeit bieten Rückmeldung von Eli zu verarbeiten und verbessert anzuzeigen.

\section{Grundlagen}
Dieses Kapitel gibt eine kurze Einführung in die, für diese Ausarbeitung und die darauf folgende Bachelorarbeit, relevanten Werkzeuge und Frameworks.
Die Eli-Werkzeuge werden durch kurze Beispiele genauer erläutert. Die Beispiele stammen aus \cite{eli},\cite{kastens}.
\subsection{Eli und die Werkzeuge}
\label{subsec:eli}
Eli als Werkzeugsystem generiert aus der in Kapitel~\ref{sec:einleitung} beschriebenen zusammengesetzten Spezifikation einen vollständigen Übersetzer. Um diesen Prozess zu verstehen, werden im folgenden Kapitel die einzelnen Spezifikationen der Werkzeuge genauer erklärt und beschrieben.
\subsubsection{Lexikalische Analyse - GLA}
\label{subsubsec:gla}
In der lexikalischen Analyse ist es Aufgabe des Scanners aus einer textuellen Eingabe, dem Quellcode, vorher spezifizierte Tokens zu isolieren. Die Tokens identifizieren die einzelnen Bestandteile der Eingabe, zum Beispiel Schlüsselwörter, Literale und Operatoren. Zur Spezifikation der Tokens werden reguläre Ausdrücke verwendet, die innerhalb eines Scanners als deterministischer endlicher Zustandsautomat abgebildet werden, der der Regel des längsten Weges folgt. In Eli übernimmt die Generierung eines solchen Scanners GLA. Die Eingabe für GLA besteht aus einer oder mehreren Dateien, die beispielhaft in Abbildung~\ref{listing:gla} dargestellt sind.

Die erste Zeile der Spezifikation beschreibt durch einen regulären Ausdruck, eine Zahl in hexadezimaler Darstellung. Die Definition lässt sich lesen als eine 0 gefolgt von einem x, egal ob groß oder klein geschrieben, gefolgt von einer oder mehreren Ziffern in Hexadezimalschreibweise.
Die durch diese Definition spezifizierten und durch den Scanner isolierten Tokens sind die Ausgabe dieser Phase und sind somit die Eingabe für die syntaktische Analyse.
%\lstset{language=<Sprache>}
\renewcommand*\lstlistingname{Abbildung}
\begin{lstlisting}[label=listing:gla,numbers=left,frame=tlRB,captionpos=b,caption=Auszug aus einer gla-Spezifikationsdatei \cite{kastens},basicstyle=\ttfamily\fontsize{10}{10}\selectfont]
HexInteger:  $0[Xx][0-9A-Fa-f]+
Identifier:  C_IDENTIFIER
\end{lstlisting}

\subsubsection{Syntaktische Analyse - Cola/PGS}
In der syntaktischen Analyse ist es die Aufgabe des Parsers den Quellcode, beziehungsweise die Folge von Tokens aus der lexikalischen Analyse, auf syntaktische Korrektheit zu überprüfen. Für den Parser wird eine konkrete Syntax als kontextfreie Grammatik definiert. Diese Grammatik enthält als Terminale, die in der lexikalischen Analyse definierten Tokens.
In Eli erfolgt die Generierung eines solchen Parser durch Cola oder PGS. Beide Pasergeneratoren arbeiten nach tabellen-gestützten Verfahren, wobei Cola zusätzlich noch optional einen direkt implementierten - Parser anbietet.

Die Spezifikation für Cola beziehungsweise PGS wird in einer con - Datei festgelegt und hat die in Abbildung~\ref{listing:con} dargestellte Struktur. Hierbei handelt es sich um das formale Kalkül der kontextfreien Grammatik (in EBNF). 
%\lstset{language=<Sprache>}
\renewcommand*\lstlistingname{Abbildung}
\begin{lstlisting}[label=listing:con,numbers=left,frame=tlRB,captionpos=b,caption=Auszug aus einer con-Spezifikationsdatei \cite{kastens},basicstyle=\ttfamily\fontsize{10}{10}\selectfont]
Program:	Block.
Block:		'{' Declarations Statements '}'.
Declarations:	Declarations Declaration / .
Statements:	Statements Statement / .
\end{lstlisting}
%\lstset{language=<Sprache>}
Zusätzlich zur Überprüfung der syntaktischen Korrektheit ist es Aufgabe des Parsers, abstrakte Strukturbäume aus der Sequenz von Tokens zu generieren. Um dies zu ermöglichen, werden dem Parsergenerator zusätzliche Anknüpfungen zur Baum-Konstruktion mitgegeben. Diese werden mithilfe des Eli internen Maptools generiert. Sie basieren auf der konkreten Syntax und einer Spezifikation für das Maptool in Form einer map-Datei. In dieser Datei werden Mapping-Regeln und symbolische Äquivalenzklassen definiert, sodass das Maptool in der Lage ist eine abstrakte Syntax zu erzeugen. 

Abbildung~\ref{listing:map} zeigt eine konkrete Syntax mit dazugehörigen Mappings/Regeln. Durch diese Regeln werden semantisch unwichtige Terminale sowie Kettenproduktionen identifiziert und durch das Tool entfernt.
Betrachtet man Zeile 16 so zeigt die Regel BinOpr ::= CmpOpr AddOpr MulOpr, dass alle Terminale die zu binären Operatoren gehören (Produktionen Zeile 7-9) weggelassen werden, da die zugehörigen Nicht-Terminale direkt auf BinOpr abgeleitet werden. 
\renewcommand*\lstlistingname{Abbildung}
\begin{lstlisting}[label=listing:map,numbers=left,frame=tlRB,captionpos=b,caption=Vergleich einer konkreten Syntax mit dazugehörigen Mappings \cite{kastens},basicstyle=\ttfamily\fontsize{10}{10}\selectfont]
Konkrete Syntax:

Expression: Expression CmpOpr Sum / Sum.
Sum: Sum AddOpr Factor / Factor.
Factor: Factor MulOpr Term / Term.
Term: NegOpr Term / Operand.
CmpOpr: '<' / '<=' / '==' / '!=' / '>=' / '>' / 'in'.
AddOpr: '+' / '-' / '||'.
MulOpr: '*' / '/' / '%' / '&&'.
NegOpr: '-' / '!'.

Abstrakte Syntax:

MAPSYM
Expr ::= Expression Sum Factor Term Operand.
BinOpr ::= CmpOpr AddOpr MulOpr.
UnOpr ::= NegOpr.
\end{lstlisting}
\subsubsection{Semantische Analyse - Liga}
Innerhalb der Phase der semantischen Analyse wird Namens - sowie Typanalyse betrieben. Die Namensanalyse sorgt dafür, dass vorkommende Bezeichner eindeutigen Repräsentanten von Programm Entitäten zugeordnet werden, sowie Definition der Gültigkeitsbereiche von Bezeichnern. Die Typanalyse hat die Aufgabe den Typ eines Programmkonstrukts zu bestimmen. Diese Analysen werden auf Basis des in der syntaktischen Analyse generierten abstrakten Strukturbaums betrieben, indem Berechnungen und Abhängigkeiten während eines Baumdurchlaufs durchgeführt beziehungsweise identifiziert werden. Das formale Kalkül an dieser Stelle sind attributierte Grammatiken.

Um die beschriebenen Auswertungen innerhalb des Baums durchführen zu können, muss ein Attributauswerter generiert werden. Die Generierung eines Attributauswerters kann mit dem Werkzeug Liga in Eli vorgenommen werden. Als Eingabe erhält es eine Spezifikation in der Sprache Lido und generiert daraus eine Attributauswerter der die semantische Analyse für jeden korrekten abstrakten Strukturbaum vornehmen kann. Abbildung~\ref{listing:lido} zeigt einen Ausschnitt einer Lido-Spezifikation für die Namensanalyse.
\begin{lstlisting}[label=listing:lido,numbers=left,frame=tlRB,captionpos=b,caption=Ausschnitt einer Lido-Spezifikation für die Namensanalyse \cite{kastens},basicstyle=\ttfamily\fontsize{10}{10}\selectfont]
ATTR Sym: int;
CLASS SYMBOL IdentOcc COMPUTE SYNT.Sym = TERM; END;
SYMBOL Program INHERITS RootScope END;
SYMBOL VarNameDef INHERITS IdDefScope, IdentOcc END;
SYMBOL VarNameUse INHERITS IdUseEnv, IdentOcc, ChkIdUse END;
\end{lstlisting}
\subsubsection{Transformation - Pattern-based Textgenerator (PTG)}
Das Werkzeug PTG (Pattern-based Textgenerator) dient der Erstellung von strukturierten Texten in beliebigen Sprachen. Als Spezifikation dafür wird eine ptg-Datei verwendet, die Pattern zur strukturellen und textuellen Definition des Ausgabetextes enthält.

Im folgenden wird das Verfahren an einem kleinen Beispiel aus \cite{eli} genauer beschrieben:
Angenommen der Nutzer möchte eine geklammerte binäre Baumstruktur darstellen. Der Baum sei wie folgt aufgebaut:
\begin{center}((1.nil).(2.(3.nil))\end{center}
Dazu werden in PTG folgende Pattern definiert :
\begin{lstlisting}[label=listing:ptg_1,frame=tlRB,captionpos=b,caption=PTG Spezifikation \cite{eli},basicstyle=\ttfamily\fontsize{10}{10}\selectfont]
     Pair:   "(" $ "." $ ")"
     Nil:    "nil"
     Numb:   $ int
\end{lstlisting}
Für jedes dieser Pattern generiert PTG eine interne Funktion, die der Anwendung des Patterns entspricht. So ergibt sich aus den in Abbildung~\ref{listing:ptg_2} dargestellten Funktionsaufrufen, mithilfe der PTG Ausgabefunktion, die gewünschte Repräsentation eines geklammerten binären Baums.
\begin{lstlisting}[label=listing:ptg_2,frame=tlRB,captionpos=b,caption=PTG Spezifikation \cite{eli},basicstyle=\ttfamily\fontsize{10}{10}\selectfont]
   PTGOut (
     PTGPair (
        PTGPair(PTGNumb(1), PTGNil()),
                PTGPair(PTGNumb(2), PTGPair(PTGNumb(3), PTGNil()))
        ));
\end{lstlisting}

\subsection{Eclipse}
Eclipse \cite{eclipse} ist eine moderne Entwicklungsumgebung zur Entwicklung von Software. Es ist modular gestaltet, sodass ein fester Kern an grundlegenden Funktionalitäten zur Verfügung steht. Hierzu gehören integrierte Editoren, die Syntaxhervorhebung, Kontextvervollständigung und Fehlerkennzeichnung anbieten. 
Durch die Modularität von Eclipse ist es möglich, eigene Softwaremodule (Plugins) zu integrieren. Die Plugins können auf grundlegenden Funktionen aufbauen, um so die Entwicklungsumgebung an spezifische Anforderungen anzupassen.
Eclipse bietet weitere Editor spezifische Funktionen, die das Arbeiten erleichtern. Hierzu gehören Templates, Code Folding sowie Querverweise. 

Templates sind vom Nutzer oder System vordefinierte Codestücke, die es ermöglichen häufig benutzte Codefragment auf einfachere Weise einzufügen. Zum Beispiel die main-Methode in Java. Durch die Eingabe von “main” erkennt Eclipse diese Zeichenkette und generiert eine leere main-Methode.

Code Folding wird zur Strukturierung von langen Quelltexten genutzt. Es ermöglicht den Rumpf von Blöcken auszublenden/einzuklappen.
Zusätzlich bietet Eclipse die Verfolgung von Querverweisen in einem Java-Dokument an, das ermöglicht zum Beispiel von der Anwendung eines Bezeichners zu dessen Definition zu springen.

Eclipse bietet durch seine Erweiterbarkeit und grundlegenden Funktionen eine gute Basis für die Entwicklung einer Entwicklungsumgebung. Hinzu kommt, dass das typische Eclipse-Look-and-Feel den meisten Anwendern, durch den Einsatz in diversen Softwareentwicklungsprojekten bekannt ist und somit keine große Eingewöhnungsphase nötig ist um mit der Entwicklungsumgebung in bisher unbekanntem Kontext arbeiten zu können.
\hyphenation{ Text-editor }
\subsection{XText}
\label{subsec:xtext}
XText \cite{xtext} ist ein Open-Source-Framework für Eclipse, dass die Sprachentwicklung für anwendungsspezifische Sprachen vereinfacht. Xtext bietet die Möglichkeit, auf Basis einer kontextfreien Grammatik in EBNF (Erweiterte Backus-Naur-Form) einen Parser für die so definierte Sprache zu entwickeln. Zusätzlich zu dem Parser generiert Xtext ein Klassenmodell für den abstrakten Sturkturbaum als EMF-Modell(Kapitel~\ref{subsec:emf}). Außerdem wird ein in Eclipse integrierter Texteditor generiert, für den auf Basis der Xtext-Spezifikation ( der kontextfreien Grammatik in EBNF ) Funktionen wie Syntaxhervorhebung, statische Analyse und Autovervollständigung berechnet werden.

In dieser Arbeit werden die einzelnen Eli-Teilspezifkationen in eine entsprechende Xtext-Spezifikation umgewandelt, um so den Parser, das EMF-Modell und den Texteditor für die Sprache der Teilspezifikation zu generieren. Auf dieser Grundlage werden die in Kapitel~\ref{sec:anforderungen} präzisierten Anforderungen umgesetzt.
\subsection{EMF - Eclipse Modeling Framework}
\label{subsec:emf}
Das Eclipse Modeling Framework \cite{emf} - kurz EMF, ist ein Framework für Eclipse, dass Schnittstelle zwischen Modellspezifikation und konkretem Javacode ist. Das Framework ermöglicht dem Benutzer Modelle zu spezifizieren und daraus automatisiert Javacode für die weitere Benutzung zu generieren. EMF gilt aufgrund der Vorteile gegenüber selbst implementierten Modellen als quasi-Standard innerhalb von Eclipse. Zu diesen Vorteilen gehören beispielsweise automatische Serialisierung sowie Validierung der Modelle, sowie der Einsatz von Code-Generatoren, die im Allgemeinen für weniger Fehlerquellen und reduzierten Wiederholungen sorgen.

Der in Kapitel~\ref{subsec:xtext} beschriebene ANTLR-Parser generiert anhand seiner Parsersyntax, der Xtext-Spezifikation und der textuellen Eingabe, dem Quellcode, ein EMF-Modell das den abstrakten Strukturbaum repräsentiert. Auf Basis dieses Modells arbeiten die Funktionen der syntaxgestützen Editoren. Somit wird EMF als Grundlage für die interne Datenhaltung der einzelnen Teilspezifikationen genutzt. Im späteren Verlauf der Arbeit wird es nötig sein, die EMF-Modelle miteinander zu verbinden, um die in Kapitel~\ref{subsec:sprachuebergreifend} angesprochene sprachübergreifende Autovervollständigung zu ermöglichen.
\section{Anforderungen / Zielsetzung}
\label{sec:anforderungen}
In diesem Kapitel soll die Aufgabenstellung dieser Bachelor-Arbeit präzisiert werden. Die Anforderungen lassen sich in die folgenden vier Kategorien unterteilen: Die Entwicklung der syntaxgestützen Editoren mit Xtext, die Erweiterung dieser Editoren um eine sprachübergeifende Vervollständigung auf Basis der EMF-Modelle, sowie die Kommunikation zwischen Eclipse und Eli die sich in das Benutzerinterface innerhalb von Eclipse und die Feedbackmechanismen unterteilen.

\subsection{Syntaxgestützte Editoren}
\label{subsec:syntax_Editor}
Ziel ist es, eine Eclipse-Entwicklungsumgebung um Editoren für die in Kapitel~\ref{subsec:eli} vorgestellten Spezifikationssprachen, zu erweitern. Zur Generierung dieser Editoren wird das in Kapitel~\ref{subsec:xtext} vorgestellte Plugin Xtext verwendet. Dadurch ist es nötig für jede der Spezifikationssprachen eine Xtext-Spezifikation zu entwicklen, die die Syntax der Sprachen abbildet. Mithilfe von Xtext sind die Editoren nach der Generierung bereits mit Grundfunktionalitäten wie Syntaxhervorhebung und syntaktischer Fehlerkennzeichnung ausgestattet.

\subsection{Sprachübergreifende Vervollständigung}
\label{subsec:sprachuebergreifend}
Unabhängig von den durch Xtext implementierten Funktionen gilt es zu untersuchen, inwieweit sprachübergreifende Beziehungen zwischen den Teilspezifikationen bestehen und wie diese ausgenutzt werden können. Hierbei wird geprüft, ob durch die Beziehungen, eine in Eclipse übliche Kontextvervollständigung implementiert werden kann die sprachübergreifend funktioniert. Es soll zum Beispiel die Möglichkeit bestehen, ein in der lexikalischen Analysephase definiertes Token (in einer gla-Datei) als Auswahlmöglichkeit in der syntaktischen Analysephase (in einer con-Datei) zur Verfügung zu stellen. Für diese Funktionalität müssen die durch Xtext generierten EMF-Modelle um ein globales Modul, zur Speicherung der nutzbaren Tokens/Bezeichner zwischen den Modellen erweitert werden.

\hyphenation{ Teil-spe-zifikationen }
\hyphenation{ E-clip-se }
\subsection{Benutzerinterface für Eli in Eclipse}
Zusätzlich zu den syntaxspezifischen Funktionen gilt es, die in Kapitel~\ref{sec:einleitung} vorgestellte Arbeitsweise mit einer spec-Datei zu optimieren. Es soll möglich sein, eine spec-Datei als Projekt zu verwalten. Das bedeutet, dass innerhalb der spec-Datei referenzierte Teilspezifikationen als Unterknoten innerhalb des Projekt-Views/Package-Views von Eclipse angezeigt und verwaltet werden können. Es soll außerdem möglich sein, dieses Projekt direkt an Eli zu übergeben, zum Beispiel durch einen entsprechenden Compile/Run-Befehl (Run-Button in Eclipse sowie Kontextmenü). Zusätzlich wäre es sinnvoll, wenn die Arbeitsumgebung es dem Entwickler ermöglicht nur Teilspezifikationen an Eli zu übergeben. Diese Funktion erlaubt es, Teilspezifikationen schnell zu verifizieren. Um dies zu ermöglichen muss die Teilspezifikationen ebenfalls in einer spec-Datei zusammengefasst werden, die an Eli übergeben werden kann.
\subsection{Schnittstelle für Feedback}
Durch die Übergabe einer Teilspezifikation, in Form einer spec-Datei kann Eli den entsprechenden Teil des Übersetzers generieren. Hierbei kann Eli Fehler finden, die durch die syntaktische Fehleranalyse innerhalb der Eclipse-Editoren nicht bemerkt wurden. Um das Feedback von Eli zu verarbeiten, muss eine Schnittstelle zwischen Eclipse und Eli so implementiert werden, dass die Fehler die Eli auf der Standard-Ausgabe darstellt, von Eclipse abgefangen und weiterverarbeitet werden. 
An dieser Stelle muss evaluiert werden, ob es möglich ist, die abgefangenen Fehler durch grafische Hervorhebung in der fehlerhaften Datei direkt anzuzeigen. Es ist jedoch Mindestvoraussetzung, dass die Fehler in der Eclipse-Konsole aufgelistet werden.

Eclipse hat die Eigenschaft Quellcode, während der Eingabe zu verifizieren. Dies gilt für syntaktische wie auch semantische Korrektheit. Diese Art der stetigen Fehlerüberprüfung, wäre ein zusätzliches wünschenswertes Feature der Entwicklungsumgebung. Da die syntaktische Korrektheit bereits durch die Editoren-Plugins gewährleistet wird, muss die semantische Überprüfung integriert werden. Die Überprüfung soll durch Eli geschehen. Hierzu wird es nötig sein, unvollständige Spezifikationen analysieren zu lassen. Bisher konnte ich keine Informationen zu dieser Arbeitsweise mit Eli finden, aus diesem Grund muss die Machbarkeit dieser Funktionalität genauer untersucht werden.
Durch die Schnittstelle zwischen Eli und der Entwicklungsumgebung sollen die Fehler aufgedeckt und angezeigt werden. Hier müssen die Antwortzeiten von Eli zu den entsprechenden Operationen, zum Beispiel die Überprüfung auf eine verarbeitbare Grammatik, untersucht werden. Sollten die Antwortzeiten nicht innerhalb eines akzeptablen Zeitintervalls liegen, in dem eine schnelle und störungsfreie Arbeit gewährleistet werden kann, besteht die Möglichkeit, die Operationen innerhalb der Entwicklungsumgebung zur direkten Benutzerinteraktion anzubieten, zum Beispiel in Form eines Buttons oder Kontextmenü-Eintrags. So hat der Nutzer die Möglichkeit zu entscheiden, wann er die entsprechenden Operationen anstößt. Hier muss eine Auswahl an Operationen getroffen werden, die sinnvoll mit den in Kapitel~\ref{subsec:eli} vorgestellten Spezifikationssprachen vereint werden können.
\section{Ähnliche Ansätze}
Dieses Kapitel dient der Abgrenzung der anstehenden Bachelor-Arbeit zu bereits existierenden Arbeiten.
\subsection{Literate}
\label{subsec:beister}
Anstelle der in Kapitel~\ref{sec:einleitung} vorgestellten .spec-Datei bietet Eli auch noch eine weitere Möglichkeit, eine Spezifikation zu verfassen. Diese Spezifikation beruht auf dem Konzept von Literate Programming \cite{knuth}. Dieses Konzept zielt darauf ab, den Quelltext eines Programms gemeinsam mit der dazugehörigen Dokumentation zu pflegen. Abbildung~\ref{listing:fw} zeigt einen Auszug aus einer FunnelWeb-Spezifikation für Eli. FunnelWeb ist ein Makro Präprozessor, der für das verweben (weaving) von Quellcode und Dokumentation verantwortlich ist.  In diesem Auszug wird deutlich, dass Teilspezifikationen zum Beispiel für GLA in das Funnelweb-Dokument verwoben sind - Zeilen 6-9. Zeile 5 hingegen ist ein Kommentar und gehört somit zur Dokumentation des Quellcodes. 
%\lstset{language=<Sprache>}
\renewcommand*\lstlistingname{Abbildung}
\begin{lstlisting}[label=listing:fw,numbers=left,frame=tlRB,captionpos=b,caption=Auszug aus einer FunnelWeb-Spezifikation \cite{kastens},basicstyle=\ttfamily\fontsize{10}{10}\selectfont]
@=~
~p maximum_input_line_length = infinity
Example of a simple compiler specification for Eli.

Scanning
~O~<e2d.gla~>~{
Id:     $[a-z]+ [mkidn]
Numb:   $([1-9][0-9]*) [c_mkint]
~}

Parsing
~O~<e2d.con~>~{
S : E.
E : E '+' T.
[...]
\end{lstlisting}
Frederic Beister hat sich in seiner Arbeit \cite{literate} mit der Implementierung einer Entwicklungsumgebung für die FunnelWeb-Spezifikation in Eli beschäftigt. Die unter dem Namen LITERATE entwickelte Arbeitsumgebung bietet wesentliche Vorteile bei der Arbeit mit Eli im FunnelWeb Kontext. Komfortfunktionen wie Syntaxhervorhebung und Autovervollständigungen konnten in LITERATE implementiert werden.
Diese Funktionalitäten lassen sich allerdings nur auf die FunnelWeb-spezifische Syntax selbst anwenden und nicht auf die Teilspezifikationen, die für GLA, Cola, PGS, etc. benötigt werden. Frederic Beister kam zu dem Ergebnis, dass es nicht ohne weiteres möglich ist Tangling-Editoren für eingebettete Sprachen mithilfe von Xtext zu generieren. Aus diesem Grund wird sich diese Bachelor-Arbeit auf die Eli-Teilspezifikationen beschränken und nur für diese Spezifikationsdateien Komfortfunktionen anbieten.
\subsection{Lama}
Lama \cite{lama} ist ein Werkzeug, das im Rahmen einer Studienarbeit von Rüdiger Hanke entwickelt wurde. Hierbei handelt es sich um eine in Java entwickelte grafische Benutzerschnittstelle zur Arbeit mit Eli. Lama ermöglicht es dem Nutzer eine Vielzahl von Eli-Kommandos einfach zu bedienen. Zusätzlich kann der Umfang der Kommandos leicht erweitert und individuell eingestellt werden. Lama bietet hierfür entsprechende Bedienelemente und ersetzt somit die textuelle Eingabe in Eli. Das Werkzeug benutzt keinen speziellen Editor, sondern verwendet einen vom Nutzer festgelegten. Im Gegensatz zu Lama wird diese Arbeit keine so detaillierte Benutzerschnittstelle bieten, da der Fokus auf der Entwicklung von syntaxgestützten Editoren für die Eli Teilspezifikationen liegt.
\hyphenation{Benutzer-oberfläche}
\subsection{Eli Development Tools}
Bei den Eli Development Tools handelt es sich um Eclipse-Plugin, das von Anthony M. Sloane und William M. Waite im Jahr 2005 in \cite{Sloane:2005:ESU:1705513.1705669} vorgestellt wurde. Das Plugin bietet eine im Eclipse-Stil verbesserte Plattform für die Entwicklung mit Eli. Neben Grundfunktionalitäten wie Syntaxhervorhebung, Codevervollständigung und einer Projektansicht, versteckt es die textuelle Eingabeaufforderung von Eli durch eine grafische Benutzeroberfläche, die die Arbeit mit Eclipse erleichtert.

Bisher konnte bis auf die in \cite{Sloane:2005:ESU:1705513.1705669} gefundenen Informationen nur wenig über die genauen Funktionalitäten und Möglichkeiten der Eli Development Tools in Erfahrung gebracht werden. Allerdings unterstützen die Tools den Nutzer genau in den beiden Aspekten, die auch diese Bachelor-Arbeit bieten wird, nämlich syntaxgestützte Editoren und verbesserte Eclipse-Eli-Schnittstelle. Somit gilt, sofern weitere Informationen zur Verfügung stehen, zu untersuchen ob Informationen zu Konzepten und Methoden aus den Eli Development Tools gewonnen werden können, die in dieser Arbeit eingesetzt werden können.

\section{Vorgehensweise / Aufgabenplanung}
Dieses Kapitel dient der Strukturierung und Planung des Vorgehens, bei der Einarbeitung, Implementierung und Ausarbeitung sowie der Evaluation. 

Zunächst muss evaluiert werden, welche Möglichkeiten Xtext in Verbindung mit Eclipse mit sich bringt. Die generierten Editoren sollten ohne große Vorkenntnisse intuitiv bedienbar sein und einen Großteil der Funktionalitäten bereits mitbringen. Hierzu gehört auch der Entwurf eines EMF Modells zur internen Datenhaltung für die Spezifikationen. Zusätzlich zu den allgemeinen Komfortmechanismen gilt es die Kontextvervollständigung auf sprachübergreifende Möglichkeiten zu untersuchen. Hier geht es darum festzustellen, an welchen Stellen der Übersetzerphasen eine übergreifende Vervollständigung sinnvoll einsetzbar ist. Hierbei kann es möglich sein, dass die EMF-Modelle zu den Teilspezifikationen erweitert werden müssen.

Um die einzelnen Editoren für die Teilspezifikationen, mithilfe von Xtext zu generieren, ist es zunächst nötig die Grammatiken der Spezifikationssprachen zu recherchieren. Diese Grammatiken müssen in die Xtext-Syntax übersetzt und gegebenfalls für diese angepasst werden. Weiterhin ist zu untersuchen, ob die geforderten Komfortfunktionen bereits durch Xtext generiert werden oder ob die generierten Editoren noch erweitert werden müssen.

Nachdem die Funktionalität der Editoren gewährleistet/implementiert ist, muss die Schnittstelle zwischen Eli und Eclipse untersucht werden. Dies sollte vor allem in Hinblick auf Feedbackmechanismen von Eli geschehen, die eine sinnvolle und hilfreiche Fehlerkennzeichnung innerhalb von Eclipse ermöglichen. Diese Fehlerkennzeichnung wäre in Form einer grafischen Fehlerhervorhebung innerhalb der entsprechenden Spezifikationsdatei wünschenswert.

Im Anschluß an die Implementierung soll eine Evaluationsphase erfolgen, in der Nutzer von Eli, beispielsweise Studenten der letzten Programming Languages and Compilers Veranstaltung, die entwickelten Arbeitsumgebung bewerten sollen. Diese Zielgruppe hat bereits Erfahrungen im Umgang mit Eli sammeln können und kann entsprechend Feeback geben. Hier geht es vorrangig um die Optimierung beziehungsweise Vereinfachung der Entwicklung mit Eli. Zusätzlich wäre es interessant Neueinsteiger zur Benutzung der Arbeitsumgebung zu befragen und festzustellen, inwiefern diese den Einstieg erleichtert.
Die Entwicklung dieser Evaluationsfragen wird während der Implementierung der sprachübergreifende Vervollständigung vorgenommen. An dieser Stelle ist es leicht Anwendungsszenarien zu identifizieren und Beispiele für Spezifikationen zu planen. Diese werden in die Evaluationsfragen eingearbeitet.
\section{Zeitplan}
\begin{landscape}
  \begin{figure}
    \includegraphics[width=1.5\textwidth]{zeitplan_html}
  \end{figure}
\begin{center}
	{\small
\begin{tabular}{|p{14cm}|c|c|}
\hline
Aufgabe & Beginn - Datum & Ende - Datum\\
\hline
\hline
\rowcolor{hellgrau}
1. Einarbeitungsphase : Xtext Spezifikation / Eli Tool Spezifikationen bzw. Recherche zu den Grammatiken & 
1.06.2012 & 22.06.2012\\
\hline
2. Schreiben der Problembeschreibung
 & 11.06.2012 & 14.06.2012\\
\hline
\rowcolor{hellgrau}
3. Schreiben des Grundlagen Kapitels
 & 22.06.2012 & 29.06.2012\\
\hline
4. Implementierung der Xtext – Editoren für die in Kapitel 2.1 genannten Spezifikationen (gla,con,ptg,lido,map) & 
22.06.2012 & 12.07.2012\\
\hline
\rowcolor{hellgrau}
5. Entwurf der sprachübergreifende Vervollständigung
 & 29.06.2012 & 13.07.2012\\
\hline
6. Implementierung der sprachübergreifende Vervollständigung
 & 13.07.2012 & 20.07.2012\\
\hline
\rowcolor{hellgrau}
7. Entwurf der Evaluationsfragen. Identifikation von Anwendungsszenarien / Planung von Beispiel - Spezifikationen
 & 13.07.2012 & 27.07.2012\\
\hline
8. Schreiben : Beschreibung der Entwurfsentscheidungen und Einschätzungen zur Vervollständigung & 
20.07.2012 & 27.07.2012\\
\hline
\rowcolor{hellgrau}
9. Entwurf und Evaluation der Schnittstelle zwischen Eclipse und Eli
 & 20.07.2012 & 27.07.2012\\
\hline
10. Durchführung der Evaluation
 & 29.07.2012 & 3.08.2012\\
\hline
\rowcolor{hellgrau}
11. Schreiben der Einleitung / restliche Kapitel und Beginn von Reviews
 & 1.08.2012 & 15.08.2012\\
\hline

\end{tabular}
}

\end{center}
\end{landscape}
\bibliography{bib}
\bibliographystyle{plain}
\end{document}



